A computer network is a geographically distributed collection of interconnected subnetworks for transporting data between nodes, such as computers. The network's topology is defined by an arrangement of client nodes that communicate with one another, typically through one or more intermediate nodes. As used herein, a client node is an endstation node that is configured to originate or terminate communications over the network. In contrast, an intermediate node is a network node that facilitates routing data between client nodes. Communications between nodes are typically effected by exchanging discrete packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
Each data packet typically comprises “payload” data prepended (“encapsulated”) by at least one network header formatted in accordance with a network communication protocol. The network headers include information that enables the client nodes and intermediate nodes to efficiently route the packet through the computer network. Often, a packet's network headers include at least a data-link (layer 2) header and an internetwork (layer 3) header, as described by the Open Systems Interconnection (OSI) Reference Model. The OSI Reference Model is generally described in more detail in Section 1.1 of the reference book entitled Interconnections Second Edition, by Radia Perlman, published September 1999, which is hereby incorporated by reference as though fully set forth herein.
Client nodes may be configured to communicate over various types of networks, ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect client nodes over dedicated private communications links located in the same general physical location, such as in a home or an office building. WANs typically connect large numbers of geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes contained in various networks.
A LAN may be operated as a broadcast domain in which each node can transmit data to every other node in the domain. For example, an Ethernet LAN may be implemented as a broadcast domain where each device in the LAN is coupled to all other devices by a shared transmission medium. Data packets in a broadcast domain are usually addressed to particular destination nodes in the domain, although packets also may be “broadcast” to every node in the domain or “multicast” to a selected subset of the nodes. In practice, a broadcasted packet may contain network topology information used to configure routing operations within the broadcast domain. Such topology information may be formatted in accordance with a conventional link-state protocol, such as the Open Shortest Path First (OSPF) protocol. Other network control information also may be broadcast or multicast among the nodes to optimize network traffic in the domain.
Management of a LAN may be simplified by arranging its network nodes in a three-tier hierarchy having separate nodes dedicated to providing user services (client tier), application functionality (application tier) and data storage (data tier). In this way, management of any one tier can be isolated from the other tiers. The client tier comprises a group of client nodes that are responsible for controlling the user interface and receiving user events. Thus, users interact and communicate with one another through nodes in the client tier. The application tier contains network nodes that provide software applications and services which may be accessed by client nodes in the client tier. The data tier comprises a set of network nodes that provide a consistent set of data and file services to nodes in the application tier. To that end, the application tier may be configured to employ conventional database management functionality.
Typical LANs comprise a set of client nodes coupled to at least one intermediate node. The intermediate node is a computer that includes a plurality of network access ports (“ports”) which are coupled via LAN segments or point-to-point links to other client and/or intermediate nodes. For instance, a port may provide a point of attachment to a LAN segment either by physically connecting the port to the LAN (i.e., a physical port) or logically associating the port with the LAN (i.e., a logical port). In general, each port is configured to communicate over a corresponding type of network or subnetwork, such as an asynchronous transfer mode (ATM) network, synchronous optical network (SONET), wireless network, frame relay network, Ethernet network, token ring network, Fiber Distributed Data Interface (FDDI) network, etc.
One or more intermediate nodes are often used to couple different LANs together, thereby allowing information to be exchanged among the interconnected LANs. For example, an intermediate node may function as a bridge which provides layer-2 “switching” functions between two or more LANs or client nodes. These functions include receiving a data packet at a first port and re-directing the packet to an appropriate destination port based on the contents of the packet's data-link header. Other intermediate nodes, such as routers, operate at higher layers within the protocol stack. Accordingly, a router may receive a data packet at a first port and then perform an address-lookup function using a destination address contained in the packet's internetwork header. The router determines over which destination port to transmit the data packet based on the result of the address-lookup operation.
Virtual Local Area Networks (VLANs)
A computer network may be segmented into one or more logical networks. That is, each logical network may include one or more network nodes which communicate with one another as though they reside on the same LAN even though at least some of the nodes may be located on different physical LAN segments. As such, each logical grouping of network nodes essentially functions as a “virtual” local area network (VLAN). Thus, a VLAN generally may be thought of as a broadcast domain in which every node in the VLAN, although not geographically located in the same physical LAN, can communicate with every other node in the VLAN.
In a typical arrangement, an intermediate node, such as a router or switch, associates a client node with a particular VLAN based on which intermediate-node port is coupled to the client node. For instance, the intermediate node may contain three ports P1, P2 and P3 which have been respectively assigned to the VLANs A, B and C. In this case, client nodes coupled to the port P1 are associated with the VLAN A, clients coupled to the port P2 are associated with the VLAN B and clients coupled to the port P3 are associated with the VLAN C. In general, any number of intermediate-node ports may be associated with the same VLAN. For example, the ports P1 and P3 both may be associated with the VLAN A. Similarly, some ports in the intermediate node may not be assigned to any VLAN. Although client nodes may be logically grouped into different VLANs based on their port associations (as described herein for purposes of discussion), those skilled in the art will also understand that the client nodes alternatively may be associated with VLANs based on other criteria, such as the clients' Media Access Control (MAC) groupings, Internet Protocol (IP) multicast groups, network-layer groupings, etc.
In many cases, it may be desirable to interconnect a plurality of intermediate nodes to extend the VLAN associations of ports in the network. Those network ports having the same VLAN designation function as if they participate in the same LAN. VLAN-configured switches and bridges are specifically configured to prevent message exchanges between ports assigned to different VLANs, thereby preserving the logical boundaries of each VLAN. Nonetheless, intermediate nodes, such as routers, operating above layer-2 can relay messages between different VLAN segments.
The Institute of Electrical and Electronics Engineers' (IEEE) promulgated a widely used standard entitled “Virtual Bridged Local Area Networks” (IEEE Std. 802.1Q) which is directed towards processing VLAN packets. To preserve VLAN associations of messages transported across trunks or links in VLAN-aware networks, the IEEE 802.1Q standard discloses including a VLAN identifier (VID) in the messages to associate the messages with their respective VLANs. The VID field defined by the IEEE 802.1Q standard is a 12-bit value that supports up to 4096 different VLANs. An intermediate node usually stores a mapping of VID values with selected ports and associates those VID values with messages transmitted through the selected ports. In other words, every time a message is received on a given port, the VID value (if one exists) for that port is incorporated into the message.
IEEE 802.1X Port-Based Network Access Control
Computer-network security often requires end users to authenticate before they are permitted to access the network. In this way, the network is protected from unauthorized users. In networks where client nodes are connected to dedicated intermediate-node ports, a user at a given client node may be authenticated at the intermediate-node port coupled to that client node. In such a port-based authentication scheme, each intermediate-node port assumes one of two possible states: “open” or “closed.” Initially, the port's state is closed, thereby preventing users at its attached client node from accessing the network. However, after a user is authenticated at the port, the port changes to an open state. The open port enables the authenticated user to access the network. Besides providing access to the network, the open port also may provide other specialized services, such as enhanced quality of service, that are not available through the port in its closed state.
A popular technique for implementing this type of conventional port-based security is described in IEEE standard entitled “Port-based Network Access Control” (IEEE Std 802.1X-2001), published July 2001, which is hereby incorporated by reference as though fully set forth herein. In this standard, a client node executes a “Supplicant” port access entity (PAE) at a client-node port, and an intermediate node executes an “authenticator” PAE at an intermediate-node port coupled to the client-node port. The Supplicant and Authenticator PAEs are configured to transmit and receive data packets formatted in accordance with the 802.1X standard.
The intermediate node's port is initially in an uncontrolled state (i.e., a “closed” state), whereby all client-node communications at the port are directed to the Authenticator PAE. The Supplicant PAE at the client node generates an 802.1X authentication request to change the intermediate node's port to a controlled state (i.e., an “open” state). As per the 802.1X standard, the request is formatted according to the Extensible Authentication Protocol (EAP) and encapsulated in a conventional IEEE 802 data frame. Advantageously, the EAP protocol is a generic protocol capable of supporting various different authentication techniques. Thus, the Supplicant PAE may generate the 802.1X authentication request in accordance with any authentication method consistent with the EAP protocol. When the client node and intermediate node are connected via a shared LAN segment, the Supplicant PAE formats the request as an EAP over LAN (EAPOL) packet and forwards it to the intermediate node.
At the intermediate node, the EAPOL packet is received by the Authenticator PAE, which processes and forwards the 802.1X authentication request to an appropriate authentication service, such as a Remote Authentication Dial-In User Service (RADIUS). The RADIUS authentication service is described in more detail in Request for Comments (RFC) 2138, entitled “Remote Authentication Dial-In User Service (RADIUS),” published April 1997, which is hereby incorporated by reference as though fully set forth herein. The RADIUS service is typically accessible to the Authenticator PAE via a pre-determined transport-layer port, such as the User Datagram Protocol (UDP) port number 1812, opened in a remote authentication server.
The payload of the authentication request sent to the RADIUS server includes a conventional “Access-Request” RADIUS message. The Access-Request message contains information, usually formatted as one or more RADIUS “Attributes,” that the RADIUS service uses to determine whether the requesting Authenticator PAE is permitted to open its intermediate-node port to the user. The Attributes may include, for example, the user's name, password, user class, intermediate-node port identifier, client-node identifier, and so forth. RADIUS Attributes and their corresponding formats are generally described in more detail in the RFC 2138 which has been incorporated by reference above.
Using the RADIUS Attributes received in the Authenticator PAE's Access-Request message, the RADIUS service provides authentication, authorization and accounting (AAA) functions to determine whether the user is authorized to communicate at the intermediate-node port. In some cases, these AAA procedures may require that a sequence of challenge-response exchanges be performed between the RADIUS service and the user. Upon completion of its AAA procedures, the RADIUS service notifies the Authenticator PAE of the user's authentication state.
If the user has been authenticated by the RADIUS service, then the service returns an “Access-Accept” message to the Authenticator PAE. In this case, the Authenticator PAE changes the intermediate-node port's state to controlled, thereby enabling the user to access the network and possibly other intermediate-node services as well. Otherwise, the RADIUS service forwards the Authenticator PAE an “Access-Reject” message indicating that the user is not authorized to access the network through the intermediate-node port. In such a scenario, the intermediate node's port remains in an uncontrolled state. This 802.1X authentication process is typically repeated periodically to verify that the user's authentication state at the intermediate-node port has not changed, e.g., from authenticated to unauthenticated.
802.1X Port-Based Network Access Control using VLANs
The RADIUS service has been extended to authenticate users over different “tunnels” accessible to the users. In this context, a tunnel is a secured communication channel in which packets are encrypted or encapsulated when they enter the tunnel and are decrypted or decapsulated upon exiting. For example, common tunneling protocols include, inter alia, the Layer Two Tunneling Protocol (L2TP) and the Point-to-Point Tunneling Protocol (PPTP). In operation, the RADIUS service may be configured, e.g., by a system administrator, to associate authenticated users with one or more tunnels over which they are permitted to communicate. For instance, the RADIUS service may associate a first authenticated user with a particular L2TP tunnel and a second authenticated user with a PPTP tunnel. Some users may be authenticated by the RADIUS service to communicate over more than one tunnel, e.g., both the L2TP and PPTP tunnels. RFC 2868, entitled “RADIUS Attributes for Tunnel Protocol Support,” dated June 2000, which is hereby incorporated by reference as though fully set forth herein, describes a set of Tunnel Attributes that the RADIUS service may use to identify which tunnels are accessible to an authenticated user. As noted in RFC 2868, the RADIUS service may disseminate the user's associated Tunnel Attributes in a conventional Access-Request, Access-Accept and/or Access-Reject message. In practice, the Tunnel Attributes are most often included in Access-Accept messages created by the RADIUS service after the user has been authenticated.
The RADIUS Tunnel Attributes include, among other things, a Tunnel-Type Attribute, a Tunnel-Medium-Type Attribute, Tunnel-Private-Group-ID Attribute and a Tunnel-Preference Attribute. The Tunnel-Type Attribute (RADIUS Attribute number 64) indicates a tunneling protocol type, such as L2TP or PPTP. The Tunnel-Medium-Type Attribute (RADIUS Attribute number 65) identifies a type of transport medium, such as conventional IEEE 802 Ethernet media. The Tunnel-Private-Group-ID Attribute (RADIUS Attribute number 81) indicates a group identifier (ID) that correlates a tunneled session with a particular group of users. The Tunnel-Preference Attribute (RADIUS Attribute number 83) specifies a tunnel preference in the event that more than one tunnel is available to an authenticated user, e.g., the user is associated with multiple Tunnel-Type Attributes.
The RADIUS Tunnel Attributes described above have been used to adapt the IEEE 802.1X port-authentication protocol for use with VLANs. To that end, the RADIUS service may notify an Authenticator PAE that a user is authenticated to participate in one or more VLANs by including a Tunnel-Type Attribute storing a predetermined value (e.g., 13) in the user's Access-Accept message. Further, the Access-Accept message also may include a Tunnel-Medium-Type Attribute whose value indicates over which type of VLAN transport medium the user is authenticated to communicate.
The particular VLAN for which the user is authenticated may be indicated by a VID value stored in a Tunnel-Private-Group-ID Attribute included in the Access-Accept message. If the user is authenticated for more than one VLAN, the Access-Accept message may contain a plurality of Tunnel-Private-Group-ID Attributes, each storing a different VID value. In such a case, the Access-Accept message also may contain a Tunnel-Preference Attribute that identifies which VID value corresponds to a “preferred” VLAN. The use of RADIUS Tunnel Attributes used to make the IEEE 802.1X protocol compatible with VLAN topologies is described in more detail in the RFC 3580, entitled “IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines,” dated September 2003, which is hereby incorporated by reference as though fully set forth herein.
Modern computer networks supporting VLANs are increasingly adopting the IEEE 802.1X port-based authentication standard using RADIUS Tunnel Attributes, as described above. Each VLAN typically corresponds to a set of users belonging to a particular user group, such as an engineering group, marketing group, finance group, etc. Depending on the size of the user groups, the number of users participating in a given VLAN may become quite large, e.g., on the order of hundreds or thousands of users. However, problems often arise when too many 802.1X authenticated users are assigned to the same VLAN, i.e., an “over-subscribed” VLAN.
For example, the amount of broadcast traffic within a VLAN may become prohibitive when the VLAN contains a large number of communicating users. More specifically, network bandwidth and system resources may become exhausted by the relatively large amounts of broadcast traffic. Moreover, the process of configuring and managing the relatively large number of 802.1X authenticated users in the VLAN may consume excessive amounts of time and administrative resources. This may be true even in highly-structured networks, such as three-tiered networks, where network nodes in different tiers are separately configured. Such configuration complexities also may be a problem when a large number of users participate in VLANs deployed in a 802.1X-configured wireless LAN, such as a campus or enterprise LAN, having a large number of wireless users.
A previous solution for managing an over-subscribed VLAN involves partitioning the VLAN into multiple smaller VLANs, each partitioned VLAN having the same characteristics, such as the same user-access privileges, network-communication protocols, etc. as the original VLAN. By way of example, consider an over-subscribed VLAN A that may be partitioned into two smaller VLANs A′ and A″. A system administrator may manually configure the network's RADIUS service to authenticate a first set of users in the VLAN A′ and a second set of users in the VLAN A″. As such, the RADIUS service may only assign each authenticated user to the VLAN that was predetermined for that user by the system administrator. In many enterprise networks, administrators currently attempt to limit the number of users that they assign to the same VLAN, e.g., less than 200 users per VLAN, to reduce the effects of broadcast traffic and configuration complexities.
Although this prior-art technique of statically assigning users, e.g., to the VLANs A′ and A″, may be effective for controlling the number of users in each VLAN, it often does not result in optimal load distribution, e.g., either in terms of VLAN population and/or bandwidth utilization. Further, the process of statically assigning users to VLANs involves a substantial amount of configuration overhead, especially in networks where the number or types of users may be dynamically changing. It is therefore generally desirable to more efficiently assign 802.1X authenticated users to different VLANs.